The Challenge of Evolving Mission Operations Tools for Manned Space Flight

In this paper we describe the impact of changing mission operations requirements on mission planning tools for human spaceflight. We use the task of planning S-Band communications for the International Space Station (ISS), as a case study. Existing planners such as the Consolidated Planning System (CPS) permit the declaration of requirements for activities, such as the set of allowed S-Band communication modes, as well as temporal constraints between activities. CPS allows operators to add activities, delete activities, and automatically generate plans; however, it is a large, monolithic system and requires significant expertise to operate. The On-board Short Term Plan Viewer (OSTPV) is suitable for viewing Short Term Plans (STPs), of roughly a week’s duration, generated with CPS, and allows users to make limited changes to plans. It is used by operators in Mission Control in the United States and Europe, and onboard the ISS. However, OSTPV does not include the capability to check STPs after modification against the constraints used to generate the original plan. Operational and technical constraints preclude using CPS to support modifications to the STP. However, recent changes to ISS operations have increased the need for modifying plans within days of plan execution, and have complicated the task of ensuring those plans meet all relevant constraints. As a result, we have developed a new tool suite to check the STP after editing, and to mark up the plan so that problems can be easily detected using OSTPV. This suite is derived from the Extensible Universal Remote Operations Planning Architecture (EUROPA), a toolbox developed at NASA Ames Research Center, and previously used to develop mission operations tools for Mars missions. We will describe these tools, discuss the operations concepts and existing tools that drive this new tool development, and discuss the future evolution of this technology. 1. International Space Station Mission Operations In this section we provide an overview of ISS operations. For more detailed overviews of this task and for insight into some of the organizational and cultural challenges, the reader is referred to [1] and [2]. ISS Planning is the complex tasks of prioritizing, negotiating, and finalizing crew activities for a given amount of time. Planning work begins when NASA’s Program Office issues a Program Document for an increment, an ISS mission timeframe that usually lasts six months. Various planning activities are done to create seven main “planning products” – some of which will be discussed in detail later in the paper. Planning activities at JSC are divided into long-term and short-term timeframes. Long-term planners are responsible for plans that are three weeks or further out, and deal mainly with negotiating crew time and constraint management. Short-term planners sit on console and deal with all real-time and next-day planning issues. Plans transition from long-term to short-term at three weeks out and are transferred from one planning system to another at one week out. Other NASA Centers and International Partners (IPs) have their own tools to do ISS planning work partly due to politics and budgets, but also because JSC’s tools do not meet everyone’s needs. For the purposes of this paper we focus on a subset of the planning process covering the following staff positions: • ISS Planning Group Leads (all three locations): Group leads manage and coordinate the work efforts and tool development initiatives of both the long-range and realtime planners at each of their respective locations. • Operations Planners (Ops Planners) at JSC: Ops Planners are long-range planners, and are tasked with establishing the initial time line for the increment. Their work begins 9 months in advance. Activities include gathering requirements for the mission, planning the activities into the mission increment and refining plans until they are execution-ready (5 daysout from execution). JSC Ops Planners are also the master integrators of the various plans generated by MSFC and Russia. • Real-Time Planning Engineers (RPE) at JSC: RPEs sit on-console making real-time changes to plans that are 05 days out. Most typically, the RPE that sits onconsole in the “front-room” (Mission Control Center) concentrates on altering the plan that is currently being executed. While the RPE, serving the “back-room” of on-console alters plans 1-3 days out that are prompted by real-time changes to the current plan being executed. 2. Current Mission Operations Tools Currently, the Long-Range Plan (LRP) is generated for roughly 6 months worth of ISS activities (equal to one ISS Increment and crew rotation). Once the major mission milestones are decided, the LRP for the Increment is generated using the Consolidated Planning System (CPS). CPS is the principal tool used by the Operational Planners. CPS permits the declaration of requirements for activities, such as the set of allowed S-Band modes, as well as temporal constraints between activities. CPS allows operators to add activities, delete activities, and automatically generate plans; however, it is a large, monolithic system and requires significant expertise to operate. For this reason, a Short-term Plan (STP) is exported from the LRP, (in the CPS system) and loaded into a light-weight web based timeline viewing tool called the On-board Short Term Plan Viewer (OSTPV). OSTPV (Figure 1) provides an intuitive interface to view the current STP. It provides a Gantt-chart like view of the plan, with bands representing pertinent information concerning ISS orbit, communications asset coverage, and activities performed by each crew member. Tool-tips allow access to a variety of related notes that further elaborate on the activity. In addition to these features, the tool allows adding and removing activities from the STP as well as changing the times of a subset of the scheduled activities. Real-time Planning Engineers (RPEs), both in the United States and International, as well as astronauts onboard ISS, can examine the STP this tool; onboard, crew use OSTPV via the Personal Computing Systems called SSCs (Space Station Computers). Once approved, the Short Term Plan (STP) is converted into the OSTPV plan one week out from the date of plan execution. The timeline data from CPS is exported into OSTPV without all the constraint Figure 1. On-board short term plan viewer interface. modeling, activity dependencies, and procedural instructions. JSC generates STP Notes to fill in the information gaps. STP Notes is a Microsoft Word document that outlines any special instructions or procedural steps associated with an ISS activity. JSC generates STP Notes from the procedural data included in the CPS-formatted STP plan. Any activity deviations from the master plan are recorded in the STP Notes. OSTPV also provides limited ability to modify plans, either by adding late-breaking activities or by moving activities. With the advent of S-Band requirements, moving activities may lead to violated S-Band constraint violations that cannot be easily checked within OSTPV. Furthermore, late-breaking activities that force changes in the S-Band plan may require extensive replanning that also cannot be supported by OSTPV. Changes to the plan are requested via a Planning Product Change Request (PPCR). It takes three individuals to approve the PPCR before any changes are made. Once the request is approved, changes must be made to both CPS and OSTPV systems as they are not linked. At the same time, any changes made at JSC must be manually made at MSFC and the IPs. The need for intense manual reviews is increased as the plan transitions from CPS into OSTPV because constraint models that were embedded in the CPS plan are stripped of the file. This requires the Lead Realtime Planning Engineer (RPE) to inherently know the constraint models so that she/he may act quickly in a real-time, re-plan situation and for more iterative manual reviews to be conducted by the execution team (flight controllers, experts and specialists). 3. Evolving Needs, Revising Plans The first human crew occupied the International Space Station (ISS) in 2000. Since then, ISS has been continuously occupied, and undergoing sustained development. Evolving operations needs have led to changes in ISS operations software. In order to respond to this need, NASA Ames Research Center and NASA Johnson Space Center have engaged in a sustained effort to develop new mission operations tools. An overview of these efforts is provided in [6]. Among these efforts is the need for improved capability of the RPEs to determine when proposed changes to the daily plan may violate constraints. In particular, the addition of new solar arrays installed on Flights 13 and 10.A in 2007 along with the impending installation of new lab modules from both JAXA (Japanese Space Agency) and ESA (European Space Agency), required extending the S-Band telemetry format to capture all necessary data. In response to this need, activities on ISS are constrained to use different S-Band formats in order to ensure the needed telemetry can be sent to ground. Only one S-Band mode may be active at any time, but any number of activities may execute concurrently as long as they are allowed to use the active mode. While changing modes is essentially instantaneous, a Swap activity of fifteen minutes’ duration must be scheduled to implement the changeover at the designated time. (Add more specifics here; specifics of packet format and telemetry downlinked, frequency of PPCRs, PHALCON’s need to run procedures with unpredictable S-band needs in partiucular.) This new mode of operations imposes added complexity on management of the STP. An activity occurring during an interval of time constrains the SBand mode at that time. The set of S-Band modes employed over time (i.e. the S-Band plan) may be updated, requiring validation of the new S-Band mode plan against the rest of the STP. Furthermore, activities may be able to use several possible S-Band modes. Thus, new activities may only be added at times such that a compatible S-Band mode is used in the current S-Band plan. Also, problems that arise can be fixed by either changing the time of activities or by changing the S-Band mode the activity uses. Activity S-Band requirements are collected using a tool called LISA; however, S-Band requirements are added to CPS by hand. As previously stated, the S-Band requirements are not exported to OSTPV plans. Thus, it is possible to change the plan and violate the rules without knowing it. Finally, there is a desire to minimize the number of times each week that packet formats are swapped, which introduces complexity into the scheduling of activities. We now describe the way the S-Band constraints are captured by CPS, how the CPS plans are exported for use by OSTPV, and how difficult it can be to find problems with S-Band constraints after changes are made to the STP. At present there are 9 S-Band modes, described by 3-letter codes; the modes are JJJ, JJK, JJL...JLL. For each individual activity in the STP, CPS has a set of rules that govern how it must be scheduled. This amounts to a set of legal S-Band modes that may be used while the activity is executing. The S-Band mode rules are captured in one or more rules that enumerate the set of legal S-Band modes. Due to the limitations on the rules language, the modes are represented in CPS as the integers from 1-9; mode JJJ is represented as 1, mode JJK as 2, and so on. CPS supports an AND-OR tree syntax for rules; a disjunction of rules is in order to capture the complete set of modes ( shown in Figure 2). In the OSTPV representation of the STP, activity descriptions include references to S-Band modes employed, if applicable; however, these references use the three-letter code (Figure 4). There is no automated translation from OSTPV’s format to the CPS format. Thus, if the OSTPV plan is changed, the RPEs must know the mapping from the three-letter codes to CPS’s numbering scheme, as well as where to enter the changes in the CPS rule base, in order to ensure consistency. Furthermore, the CPS field used to denote the S-Band mode is a range of the integers from 1-9, with the smaller value specified by the field ACTV_COND_RANGE_MIN_TIME , and the larger value specified by the field ACTV_COND_RANGE_MAX_TIME (Figure 2). These fields are easily confused with activity time parameter names, leading to further potential for error. There is a further complication involving correlating activity rules in CPS and activity descriptions in OSTPV. The tools use different schemes to enforce unique identifiers amongst activities. The CPS rule base includes a relational table correlating the OSTPV and CPS activity identifiers (Figures 2 and 4), but it is difficult for RPEs to chase down the correct activity in the CPS rule base. Worse yet, the relation is implicit, and the parameter names used in the two schema increase the chances for confusion; the CPS schema’s parameter is named the OSTPV-ID, and the OSTPV schema’s parameter is named the CPS-ID. On rare occasions, the OSTPV identifier may be re-used when two CPS users create an OSTPV-readable version of the STP, which further complicates the issue. Finally, if a new activity is added to the STP in OSTPV, it is impossible to associate it with an activity added to CPS. 4. Deep Space Mission Operations Tools EUROPA is a constraint-based planning framework developed at NASA Ames Research Center [4]. 1 CPS generally allows arbitrary temporal constraints on its conditions; however, usually the S-Band mode starts when the activity starts, and ends when the activity ends. SPICER_PKTSWP_AMES A000000005B51E3JSCP0 IFM-LAB1S6 MECH-T/S 3 ...